Workflow management systems are used by many organizations today to improve the efficiency with which work items are performed, by automating the process of distributing the work items to members of the organization. A workflow management system may include an electronic file storage (e.g., a database) containing information representative of work items, and a workflow application that accesses this information and disseminates it to members of the organization so that the work items may be addressed. Work items, or activities, may be categorized into particular work item types, such as “bugs”, application features, requirements, tasks, issues, action items, or any other suitable work item type. Work item types implemented by conventional workflow management systems are typically related to the development or maintenance of one or more computer systems, such as the development or maintenance of one or more software applications.
FIGS. 1 and 2 depict the function and operation of a conventional workflow management system. FIG. 1 depicts an exemplary process which may be implemented by a conventional workflow management system to resolve a software application “bug”, and FIG. 2 depicts an exemplary workflow management system configuration on which the process of FIG. 1 may be performed. In FIG. 2, system 200 includes server 210, on which resides database 215 and workflow application 217. Workflow application 217 communicates with workstations 220A-220D via network 225, which may comprise a local area network (LAN), wide area network (WAN), the Internet, other network(s), or a combination thereof. Workstations 220A-220D may be employed by operators to receive information and address work items. Respective workstations 220A-220D may each employ GUI 221A-221D to communicate with workflow application 217.
Upon the start of process 100 (FIG. 1), the bug is “opened” (i.e., made active) in act 110. For example, an operator of workstation 220A may input information via workflow application 217 to database 215 to indicate various characteristics of the bug, such as a description, its priority, the software application it affects, the platform on which the application executes, an indication that it is open and unresolved, and/or other characteristics. The process then proceeds to act 120, wherein the bug is assigned to an operator for resolution. For example, workflow application 217 may examine the information in database 215 and determine, based on various business rules, that the operator of workstation 220D is the most appropriate resource to resolve the bug. When act 120 completes, the process proceeds to act 130, wherein the operator of workstation 220D modifies the software application in an attempt to fix the bug. Upon tentatively determining that the bug is fixed, the operator may provide an indication via application 217 to be stored in database 215. The process then proceeds to act 140, wherein the tentative resolution is assigned for testing. For example, workflow application 217 may examine information in database 215 to determine that the operator of workstation 220C is the most appropriate resource to test the tentative resolution. In act 150, the application is tested, and in act 160, a determination is made as to whether the bug has been successfully resolved. If so, the process proceeds to act 170, wherein the bug is “closed” (i.e., given an indication in database 215 of having been resolved), and the process completes. If not, the process returns to act 120, so that the issue may be assigned (e.g., reassigned to the operator of workstation 220D) for resolution. In this respect, process 100 may be iterative.
With a conventional workflow management system such as system 200, it may be difficult to modify, and thus maintain, information relating to specific work item types. For example, making modifications to the manner in which information related to bugs is stored, the manner in which bugs are processed, resolved and/or managed, and/or the manner in which information on the work item type is displayed to an operator may require substantial modifications to a database (e.g., database 215) and/or a workflow application (e.g., application 217). As an example, to make changes to the way in which bugs are managed, a user may be required to change the schema of the database, modify the workflow application to implement one or more business rules differently, or both. This typically requires not only significant knowledge of the workflow management system, but also significant technical skill to develop computer programs to implement these changes effectively.